Intel Optane P4800X评测(3)：Windows绑核优化篇
据了解，使用3D XPoint Memory的Optane P4800X在国内已经开始少量供货，除了一些测试过的人之外，已经开始有采购的用户了。有朋友问我，这个卡在测试中有没有需要注意/调优的地方，以便更好地发挥其性能价值。
此外，如果说Windows Server 2012和2016的内核I/O效率有差异，您能否先预测下性能结果？
接系列前文：
《IntelOptane P4800X评测（序）：不用缓存和电容保护的SSD？》
《IntelOptane P4800X评测(1)：好钢如何用在刀刃上？》
《OptaneP4800X评测(2)：Oracle 170万TPM意味着什么？》
前面已经写过FIO和Oracle数据库的测试，这篇主要围绕Windows下的Iometer测试结果，顺便谈谈性能发挥方面的一些注意事项。水平有限，不足之处请大家多指正:）
传统中断I/O在Optane面前显出瓶颈
点击放大图片，以下同
首先解释一点，未经特别设置的情况下，我在Windows Server 2016（自带NVMe驱动）下测到的P4800X读延时最小为20μs左右，没有达到当初在《再谈3D XPoint：延时、QoS与队列深度》中列出的官方规格。Why？
Intel标称的延时是QD（队列深度）=1小于10μs，我也看了国外网站的评测，要达到这个性能传统IRQ中断设备访问模式应该是比较困难，polling（轮询）的效率会更高。而polling也分为内核态和用户态实现，如果使用FIO、Iometer这样的工具测试块设备，我在高版本Linux内核下测到了11μs左右；此外还有个“终极大法”——用户态下的SPDK，后续文章中我会给大家讲讲这部分测试。
这里顺便推荐冬瓜哥的一篇科普文《IO协议栈前沿技术研究动态（2015存储峰会分享）》
回过头来说，可能大多数企业存储用户现在还用不到polling，那么传统中断I/O的性能也有参考意义。我们接着讨论上面的对比图表：
Intel Optane P4800X与SSD P3700相比，在低队列深度的情况下IOPS和延时优势都很明显。P4800X在QD=32时就能测出最大IOPS58万，而P3700则要到QD=128才能达到标称的46万。
用Windows Server 2016上来直接测，写延时也没有低于20μs
再来看随机写。与随机读不同的是，由于SSD上有写缓存做优化合并等，低队列深度时两款卡拉不开差距（前文中我也提到了NAND闪存SSD这个Cache和保护电容往往大一些）。Intel SSD P3700在QD=8时已达最大性能18万IOPS（此时Optane P4800X为23万），而P4800X到QD=32才完全发挥出优势，我们测出的48万随机写IOPS接近50万的官方规格，此时的延迟为66μs（P3700则达到170μs）。
在《不用闪存了，Optane SSD为何还要28%的OP？》中我曾提到过，3D XPoint Memory介质不用擦除就能直接覆盖写入，所以P4800X不需要大容量DRAM写缓存的设计，平均写延时只是比读略高。而P3700在QD=16～32之间有一个交叉点，超过这个点读IOPS和延时表现就比写要好了。
对于QoS延时，SSD的写缓存就比较无力了。下一篇评测中，我还将给大家列出95%-99.999% QoS延时的对比，一些官方spec中没有的数值希望能够通过我们的测试给大家补上。
为什么要绑核：IRQ打散对CPU开销的影响
接下来一个问题，就是动辄几十万IOPS，CPU的开销如何？在Iometer里每个Worker对应一个线程，如果单一Worker测试增加QD达到一定IOPS就会把单个CPU核心耗满。我观察了这时的CPU资源占用情况，想到了一个提高性能效率的可能。
上面的截图，还是来自本系列测试使用的服务器——Dell PowerEdge R830，配置了4颗10核Intel Xeon E5-4610 1.8GHz CPU。上面是关闭超线程时每个内核显示的小窗，这样看直观一些，如果打开HT由于逻辑处理器太多只会显示一个百分比数字了。
大家可以观察到有8个CPU核心一度集中占用较高——因为我在测试中先做了8个线程的绑核操作，而后取消了绑核，按照默认方式跑8个Worker测试。后半程能够调动的CPU资源还是相当于8个核，但Windows系统自动会将其打散到多个核心上，就像irqbalance的效果。经过反复对比测试，验证了绑核设置对性能是有影响的。
不到60万IOPS，CPU总体占用率超过20%，快要接近10核1.8GHz E5-4610 CPU的处理资源了。从这一点上来看Windows的效率没有Linux高。
这里还是使用Windows Server 2016，默认超线程打开的测试结果。当QD=1时，设置绑核之后Optane P4800X的IOPS从46067提高到57858，延时从21μs降低到17μs，同时CPU占用率也有下降。可见OS的中断打散在有些情况下是有副作用的。
在一个Worker将QD增加到4时，Xeon E5-4610 v4处理器的单个1.8GHz核心开始成为瓶颈。绑核后可以测到145828 IOPS，2.8%的CPU占用率基本上代表占满了40核心中的1个，可能把其它程序的一点开销也统计进去了吧。
当Worker*QD加大到16*2时，由于已经是多线程I/O操作，绑核的效果不再明显，都可以达到Optane P4800X的最大性能。而若是在超线程关闭的情况下，绑核的表现又不一样，或者可以说不绑核测试的效果比HT打开时略差。为了不打乱大家的思路，本文还是先分析默认设置的情况。
随机写测试的情况与上面类似，QD=1时绑核效果仍然不错，而到QD=4就掉过来了。总的来说高队列深度下绑核的作用不再明显，或者有小的副作用。同时我也按照同样方式测试了Intel P3700随机写，结果和Optane P4800X类似，也就是说这一段的经验对于Windows下不同的高性能SSD都应该适用。不过NAND闪存卡的低QD随机读性能与Optane差距较大，所以绑核受益没那么多了，比如在100μs基础上降低几个微秒就不容易察觉了吧。
17μs的延时并不能让我们止步，更重要的是我也想验证不同版本操作系统下的表现，请看接下来的对比。
WindowsServer 2016输给了2012？但不是全部
可能是工程样品的缘故，我手头这块Optene P4800X最大IOPS性能偶有小幅波动。文档里标称的随机读55万，我在测试中偶有遇到52万左右的情况。
换用Windows Server 2012 R2之后，我们验证了绑核带来的效果。QD=1随机读延时降低到15μs，单个CPU核心贡献的IOPS也超过了16万，这可以说WS 2016的效率不够高吗？
注：CPU的单线程性能与主频和核心效率直接相关，我们测试的PowerEdge R830服务器支持全系列XeonE5 v4处理器，这台配置的E5-4610 v41.8GHz在Linux下单核可以轻松测出20万以上IOPS。
上面图表中我们也看到了不正常的情况：QD=32时绑核之后性能反而达不到最大IOPS，延时和CPU占用率也飙升，几乎把16个CPU核心给耗满了。如果关闭超线程，WS 2012系统下绑核没有这个问题，也许需要更进一步的调优吧。这应该不是SSD的问题，列出来只是供大家参考。
Windows Server 2012 R2随机写的情况与随机读类似。QD=1绑核在54744 IOPS时CPU总体占用率只有0.83%，相比之下WS 2016的内核效率显得低了一点。
顺序读写带宽简测
考虑到单位容量价格的因素，大数据块顺序I/O性能应该不算Optane P4800X的亮点。不过既然也有朋友问过我这方面，估计还会有人想了解吧。
Intel P3700官方指标Seq R/W: Up to 2800/2000MB/s，不过是按照MB/s = 1,000,000 bytes/second的单位，我们测试的MiB则是1,048,576bytes。
如上方图表，Optane P4800X的64KB顺序读带宽在QD=2时就达到最大值2500MiB/s了。而Intel SSD P3700的情况有点特别，QD=1时的读带宽较高，而QD增加到2-4却有些不稳定，还出现过低于1000MiB/s的情况。由于带宽测试不是我们的重点，只是短时间跑了一下没有深究，结果仅供大家参考。也不排除是我手头测试卡的个体表现。
顺序写的表现在我们意料当中，Optane P4800X在64KB QD=8时写带宽达到了2185MiB/s，比P3700高一些。
总结与展望：SPDK、QoS延时
简单回顾下本文的Iometer测试，除了P4800X未能发挥出标称的延时（原因前面解释过了）之外，我们还发现了Server 2016和2012系统效率上的小差别，以及绑核带来的效果。有些结论涉及到Windows系统的机制，不只适用于Optane和Intel SSD，希望能给大家一些参考吧。
下一篇我将转回到Linux系统。在Intel给出的图表中，同样使用单一Xeon CPU核心，Linux内核IOPS最高可以跑到40-50万IOPS，而改用SPDK之后则高达350万以上。
我估计Intel这个测试用的CPU主频达到3.5GHz左右。那么我手头PowerEdge R830服务器上的Xeon E5-4610 1.8GHz如果SPDK跑到上面列出的一半，应该也能用1个核心支撑Optane P4800X和P3700两块卡加在一起了。
事实是否真的如此？P4800X的延时究竟能降低到多少？请大家拭目以待…
注：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎在留言中批评指正。进一步交流技术，可以加我的QQ/微信：490834312。如果您想在这个公众号上分享自己的技术干货，也欢迎联系我：）
尊重知识，转载时请保留全文，并包括本行及如下二维码。感谢您的阅读和支持！《企业存储技术》微信公众号：huangliang_storage
长按二维码可直接识别关注
历史文章汇总（传送门）：http://chuansong.me/account/huangliang_storage